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Remarks 

A. Claims In The Case 

Claims 6-20 and 78 are pending in the case. Claims 6, 8, and 78 have been amended. 

B. Claim Obiections 

The Examiner rejected claim 78 based on informalities. Applicant has amended claim 
78 for clarification to recite: "receiving, for each of at least two of the selected data elements, an 
input fi*om the user specifying the place of the data element in a sequence of the two or more data 
elements." Applicant respectfully requests removal of the objection to claim 78. 

C. The Claims Are Not Anticipated by French Under 35 U.S.C. 8 102(b) 

The Examiner rejected claims 6-16 as being anticipated by U.S. Patent No. 5,794,229 to 
French et al. (hereinafter "French"). Applicant respectfully disagrees with these rejections. 

The standard for "anticipation" is one of fairly strict identity. To anticipate a claim of a 
patent, a single prior source must contain all the claimed essential elements. Hybritech, Inc. v. 
Monoclonal Antibodies, Inc., 802 F.2d 1367, 231 U.S.P.Q.81, 91 (Fed. Cir. 1986); In re 
Donahue, 766 F.2d 531, 226 U.S.P.Q. 619, 621 (Fed. Cir. 1985). 

Claim 6 has been amended to describe a combination of features including: 

storing a plurality of key definitions in a database table in a database of an 
Financial Service Organization (FSO) computer system, wherein the FSO computer 
system is configured to perform processing on FSO transaction-related data, wherein the 
key definitions in the database table are configured for use in processing FSO transaction- 
related data in the FSO computer system, wherein storing the plurality of key definitions 
in the table comprises, for each of at least two rows in the database table: 

displaying two or more key element representations on a display screen in 

data communication with the Financial Service Organization (FSO) computer 

system,; 
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receiving a selection by a user of at least two key element representations 
from the tv^o or more displayed key element representations; 

preparing a key definition from the two or more key elements 
corresponding to the at least two selected key element representations in response 
to the user selecting the at least two key element representations; and 

storing the key definition in the database table; the key definition being 
configured for use in preparing a processing key value from a transaction- 
related data in the FSO computer system 

Support for the amendments to the claims can be found in Applicant's specification at least on 
page 21, line 24 to page 23, line 12; page 27, line 20 to page 28, line 25; FIG. 10. The cited art 
does not appear to teach or suggest at least the above-quoted features of claim 6. 

Regarding the feature "storing the key definition in the database; the key definition being 
configured for use in preparing a processing key value from a transaction-related data in the FSO 
computer system", the Examiner relies on French, col. 12, line 37-col. 13, line 3. The cited 
portion of French describes storing data in a column- wise basis, wherein a query can bring in only 
those columns of data that are of interest. The Examiner states "storing the key definition is 
inherent since it is simply saving the SQL statement because the SQL statement has to be saved 
somewhere on the computer in order for it to be seen." To rely on the theory of inherency, the 
examiner must "provide a basis in fact and/or technical reasoning to reasonably support the 
determination that the allegedly inherent characteristic necessarily flows from the teachings of the 
appHed prior art." Ex parte Levy, 17 U.S.P.Q.2d 1461, 1464 (Bd, Pat. App. & hiter. 1990) 
(emphasis in original.) Inherency may not be established by probabilities or possibilities; the mere 
fact that a certain thing may result from a given set of circumstances is not sufficient. In re 
Robertson, 169 F.3d 743, 745 (Fed. Cir. 1999). Even if the SQL statement described in French 
had to be stored somewhere to be displayed, as the Examiner contends, Applicant submits that it 
is not inherent in French, and nothing in French teaches or suggests, the features of claim 6 of 
storing a plurality of key definitions in a database table, each key definition configured for use in 
preparing a processing key value from a transaction-related data in an FSO computer system. 
Moreover, Applicant submits that French does not teach or suggest storing a plurality of key 
definitions in a database table in a database of an Financial Service Organization (FSO) computer 
system, wherein the FSO computer system is configured to perform processing on FSO 
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transaction-related data, v^herein the key definitions in the database table are configured for use in 
processing FSO transaction-related data in the FSO computer system, w^herein storing the plurality 
of key definitions in the table comprises, for each of at least tv^o rov^s in the database table: 
displaying two or more key element representations on a display screen in data communication 
v^ith the Financial Service Organization (FSO) computer system, receiving a selection by a user of 
at least two key element representations fi'om the tv^o or more displayed key element 
representations; preparing a key definition fi-om the two or more key elements corresponding to 
the at least two selected key element representations in response to the user selecting the at least 
• two key element representations; and storing the key definition in the database table; the key 
definition being configured for use in preparing a processing key value fi"om a transaction-related 
data in the FSO computer system. 

Claim 6 further describes: 

wherein the processing key value is configured for use in locating a process control data 
set in the database in the FSO computer system, the process control data set comprising 
one or more process control data values and configured for use in processing the 
transaction-related data in the FSO computer system 

Regarding the feature "wherein the processing key value is configured for use in locating 
a process control data set in the database in the FSO computer system, the process control data 
set comprising one or more process control data values and configured for use in processing the 
transaction-related data in the FSO computer system", the Examiner relies on a portion of French 
which states: 

In operation, the Client(s) issue one or more SQL commands to the Server. SQL 
commands may specify, for instance, a query for retrieving particular data (i.e., data 
records meeting the query condition) fi-om the table 250. The syntax of SQL 
(Structured Query Language) is well documented; see, e.g., the above-mentioned An 
Introduction to Database Systems. In addition to retrieving the data fi^om Database 
Server tables, the Client(s) also include the ability to insert new rows of data records 
into the table; Client(s) can also modify and/or delete existing records in the table. 

For enhancing the speed in which the Database Server stores, retrieves, and presents 
particular data records, the Server maintains one or more database indexes 271 on the 
table, under control of an Index Manager. A database index, typically maintained as a 
B-Tree data structure, allows the records of a table to be organized in many different 
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ways, depending on a particular user's needs. An index may be constructed as a single 
disk file storing index key values together with unique record numbers. The former is 
a data quantity composed of one or more fields from a record; the values are used to 
arrange (logically) the database file records by some desired order (index expression). 
(French, column 7, lines 7-27). 

The Examiner states: "{col 7, lines 7-27 -the result when a SQL Query is run. The result will 
be displayed of all of the data in the SALES and DATE OF SALE colunms)". Applicant 
disagrees that French teaches or suggests the above-quoted feature of claim 6. French discloses 
a client issuing SQL commands to a server to retrieve data. A database index allows records to 
be organized in many different ways. Applicant submits that French does not teach or suggest a 
processing key value configured for use in locating a process control data set in a database in the 
FSO computer system, the process control data set including one or more process control data 
values and configured for use in processing the transaction-related data. Moreover, French does 
not teach or suggest a process control data set configured for use in processing transaction-related 
data in a financial service organization computer system. 

For at least the reasons stated above, the combination of the features of claim 6 are not 
taught or suggested by the cited art. Applicant requests removal of the rejection of claim 6 and 
the claims dependent thereon. 

Applicant submits that many of the claims dependent on claim 6 are separately 
patentable. For example, claim 7 recites, in part, "wherein the user selecting the key element 
representations, the preparing the key definition, and the storing the key definition occur during a 
configuration of the FSO computer system." The Examiner cites column 7, lines 36-67, column 
12, line 10 to column 13, line 3, and Fig. 3B of French. Applicant submits that the cited portions 
of French appear to relate to a server maintaining database indexes on tables, under the control of 
an Index Manager. In operation SQL statements received fiin the clients are processed by an 
engine of the database server system. (See, e.g., French, column 7, lines 15-38). The cited 
portions fiirther disclose queries encountered in decision support system (DSS) applications, and 
storing data in a column- wise basis to process such queries. (French, e.g., column 12, lines 10- 
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61). French does not appear to teach or suggest configuration of financial service organization 

computer systems. Moreover, claim 7 is directed to a method that includes selecting key 

element representations, and preparing and storing of a key definition occur during a 

configuration of a financial service organization (FSO) computer system. For example, 

Applicant's specification states: 

In one embodiment, the key definitions, key values, processing parameter values, 
and search masks may be constructed and stored during the configuration of the 
FSO system. Configuration of the FSO system may occur at the time the FSO 
system softv^are programs and databases are initially installed and set up for 
processing FSO transactions. Configuration of the FSO system may also occur 
after the initial configuration performed during the installation of the FSO system. 
A configuration of the FSO system that occurs after the initial configuration may 
be called a reconfiguration of the FSO system, 
(page 6, line 27 to page 7, line 4) 

Applicant submits that the cited portions of French do not appear to teach or suggest the user 
selecting the key element representations, preparing the key definition, and the storing the key 
definition occur during a configuration of a financial service organization computer system. As 
such, Applicant submits that the cited art does not appear to teach at least this feature in 
combination with the other features of the cited art. 

Amended claim 8 recites, in part, "v^herein the preparing the key definition firom the one 
or more key elements fiirther comprises the user specifying a sequence of the key elements in the 
key definition, wherein the user specifying a sequence of the key elements in the key definition 
comprises the user specifying the place of each of the selected key data element in a sequence of 
the selected key data elements for the key definition." The Examiner cites column 7, lines 2-24 
of French, which state: 

... In the foregoing employee table, for example. Position is one field, Date Hired is 
another, and so on. With this format, tables are easy for users to understand and use. 
Moreover, the flexibility of tables permits a user to define relationships between 
various items of data, as needed. 

In operation, the Client(s) issue one or more SQL commands to the Server. SQL 
commands may specify, for instance, a query for retrieving particular data (i.e., data 
records meeting the query condition) fi-om the table 250. The syntax of SQL 
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(Structured Query Language) is well documented; see, e.g., the above-mentioned An 
Introduction to Database Systems. In addition to retrieving the data from Database 
Server tables, the Client(s) also include the ability to insert nev^ rov^s of data records 
into the table; Client(s) can also modify and/or delete existing records in the table. 

For enhancing the speed in which the Database Server stores, retrieves, and presents 
particular data records, the Server maintains one or more database indexes 271 on the 
table, under control of an Index Manager. A database index, typically maintained as a 
B-Tree data structure, allows the records of a table to be organized in many different 
ways, depending on a particular user's needs. An index may be constructed as a single 
disk file storing index key values together with unique record numbers. 
(French, colunm 7, lines 2-24). 

Applicant submits that the cited portions of French appear to relate to a client issuing SQL 
commands to a server to retrieve particular data. Data indexes, such as in a B-Tree data 
structure, allow records to be organized in different ways. Applicant submits that the cited 
portions of French do not teach or suggest a method in which preparing the key definition from 
key elements further includes wherein preparing the key definition from the one or more key 
elements further comprises the user specifying a sequence of the key elements in the key 
definition, wherein the user specifying a sequence of the key elements in the key definition 
comprises the user the user inputting one or more sequence parameters, at least one of one or 
more sequence parameters specifying the place of one of a selected key data element in a 
sequence of the selected key data elements for the key definition. As such. Applicant submits 
that the cited art does not appear to teach at least this feature in combination with the other 
features of the cited art. 



Claim 1 8 recites, in part, "wherein the user defining the one or more key masks further 
comprises the user selecting a mask field value from a plurality of mask field values for each of 
the one or more mask fields in each of the one or more key masks, and wherein the plurality of 
mask field values comprises an equal mask field value and a wildcard mask field value." Claim 
18 is directed to a method that includes a user defining key mask field values for mask fields in 
one or more masks in which the mask field values include an equal mask field value and a 
wildcard mask field value. For example, Applicant's specification states: 
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In one embodiment of a search mask table, mask field values may include 
an equal mask field values and a wildcard mask field value. In one embodiment, 
an equal mask field value may be entered by the user and displayed on the search 
mask entry display screen as an equal sign as illustrated in Figure 9. In one 
embodiment, a wildcard mask field value may be entered by the user and 
displayed on the search mask entry display screen as an asterisk C'*")^ as 
illustrated in Figure 9. In one embodiment, an equal mask field value in a mask 
field may specify that, when constructing a processing key value fi-om the data 
element values in a customer account data set during processing of the customer 
account data set, the key element value in the processing key value corresponding 
to the mask field will be set to the data element value firom the customer account 
data set. In one embodiment, a wildcard mask field value in a mask field may 
specify that, when constructing a processing key value fi-om the data element 
values in a customer account data set during processing of the customer account 
data set, the key element value in the processing key value corresponding to the 
mask field will be set to the low collating value for the data type of the key 
element. 

(Applicant's specification, page 25, line 26 to page 26, line 1 1). 

The Examiner relies on Douceur, column 26, line 43 to column 27, line 62, for the above-quoted 
features of claim 18. The cited portions of Douceur discloses VALUE, MASK, and IMASK. 
Douceur further discloses that the purpose of each field differs between a pattem node and a 
branch node. The MASK field may specify the existence of a wildcard in the corresponding 
pattem. Applicant submits that Douceur does not teach or suggest a user defining the one or 
more key masks in which the user selects a mask field value from a plurality of mask field values 
for each of the one or more mask fields in each of the one or more key masks, and in which the 
plurality of mask field values comprises an equal mask field value and a wildcard mask field 
value. 

Claim 19 recites, in part, "wherein the transaction-related data comprises a credit card 
transaction, and wherein the processing parameter value comprises one or more data values 
configured for processing the credit card transaction." With regard to this feature, the Examiner 
states: 

It would have been obvious to one having ordinary skill in the art at the time 
the invention was made to have the transaction-related data comprise a credit card 
transaction, and wherein the processing parameter value comprises one or more data 
values configured for processing the credit card transaction and to modify in French 
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since French does disclose product, price, and revenue in col. 12, lines 15-25 and 
because such a modification v^ould allov^ French to have financial transaction data 
retained by a transaction processing system. 

Applicant disagrees with the Examiner's assertion. The cited portion of French states: 



SELECT Age, Gender, SUM(Revenue), COUNT(*) 
FROM Customers 

WHERE State IN CMA', *Rr, 'CT') 

AND Status = 'Active' 
GROUP BY Age, Gender; 
SELECT State, Product, SUM(Revenue), AVG(Price) 
FROM Customers 
WHERE Product <> 'b' 

AND Code = 1 
GROUP BY State, Product 



(French, colunm 12, lines 15-25) 



Applicant submits that the cited portions of French do not teach or suggest the transaction-related 
data comprises a credit card transaction, and v^herein the processing parameter value comprises 
one or more data values configured for processing the credit card transaction. Moreover, 
French is directed tov^ard solutions for "Decision Support Systems" for analytical processing. 
French appears to teach av^ay fi-om configuring records of a database for transaction processing. 
For example, French states: 

The foUov^ing description will focus on specific modifications to an SQL- 
based database server, such as System 240, for providing improved Decision Support 
query performance. 

A. DSS queries require a different design approach 

The present invention recognizes that the previously-described "needle-in-a- 
haystack" approach to information retrieval employed in OLTP [online transaction 
processing] environments is not v^ell-suited for Decision Support Systems (DSS) 
applications. DSS applications, such as those used in conjunction v^ith providing a 
"data v^arehouse," are employed for more analytical information processing. Instead 
of employing a simple query for pulling up records of a particular customer, a DSS 
query typically seeks information of a more general nature. A typical DSS query 
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would, for instance, ask how many customers living in Massachusetts purchased 
more than thirty dollars of merchandise over the past year. To satisfy a query of this 
nature, a database system would have to examine a large percentage of the actual 
warehouse data, not just a few records. 

In fact, the individual records found in a DSS query are often not of interest to the 

user Here, the sum of a particular category is more of interest to the user than the 

detail records of the particular transactions which contributed to that sum. 

The poor performance of OLTP systems in providing DSS stems from the 
architecture and design considerations underlying these systems. Quite simply, OLTP 
database engines have been architected and optimized for transaction processing to 
such an extent that thev are not well-suited for analytical processing . The problem is 
due, in part, to how information is actually stored in OLTP systems. Such systems 
store rows of records arranged in a list of data pages (i.e., page "chain"). That 
approach is well-suited for transaction processing. When a system needs to retrieve a 
particular record, it need only bring in the corresponding data page which stores that 
record. If, on the other hand, analytical processing is required, this horizontal 
approach (i.e., storing particular rows to each data page) hampers system 
performance . A DSS query might, for instance, require the system to examine values 
in a particular column (or a few colxamns). Since the information is stored by row 
(i.e., horizontally) and not by column (i.e., vertically) in OLTP systems, those 
systems have to bring in all data pages in order to perform the DSS query. The 
underlying storage mechanism employed in OLTP systems, while perhaps optimal 
for transaction processing, is clearly suboptimal for Decision Support applications . 
Typical DSS queries look at several tables but only a small number of columns 
(relative to the total number of columns for a table). A system using the OLTP 
approach to storing data would have to bring in a multitude of data pages-data pages 
which largely consist of information which is simply not of interest in DSS queries. 
(French, column 8, line 15 to column 9, line 7) (emphasis added) 

Thus, French appears to teach away from the features of claim 19 wherein the processing 
parameter value includes data values configured for processing transactions. For at least this 
reason. Applicant submits that it would not have been obvious to modify French as proposed by 
the Examiner such that a processing parameter value includes data values configured for 
processing a credit card transaction. 

D. The Claims Are Not Obvious over French Under 35 U.S.C, S 103(a) 

The Examiner rejected claim 78 as being obvious over French. Applicant respectfiilly 
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disagrees with this rejection. 

hi order to reject a claim as obvious, the Examiner has the burden of estabUshing a prima 
facie case of obviousness. In re Warner et al., 379 F.2d 1011, 154 U.S.P.Q. 173, 177-178 
(C.C.P.A. 1967). To establish a prima facie obviousness of a claimed invention, all the claim 
limitations must be taught or suggested by the prior art. (emphasis added) In re Royka, 490 F.2d 
981, 180 U.S.P.Q. 580 (C.C.P.A. 1974), MPEP § 2143.03. "All the words in a claim must be 
considered in judging the patentability of that claim against the prior art." (emphasis added) In 
^ re Wilson, 424 F.2d 1382, 1385 (C.C.P.A. 1970). 

Claim 78 has been amended to describe a combination of features including: 

receiving, for each of at least two of the selected data elements, an input from the user, 
the input comprising a sequence parameter specifying the place of the data element in a 
sequence of the two or more data elements, 

the selected data elements in the user-specified sequence defining a user-defined key, 
the user-defined key being configured during a configuration of the FSO computer 
system and describing a location of one or more corresponding data element values 
stored in an FSO database 

Support for the amendments to the claim can be found in Applicant's specification at least on 
page 21, line 24 to page 23, line 12; and FIGS. 6 and 7. The cited art does not appear to teach or 
suggest at least the above-quoted feature of claim 78. 

Claim 78 is directed to a method in which, during a configuration of a financial service 

organization computer system, for each of two or more selected data elements, the user enters a 

sequence parameter that specifies the place of the data element in a sequence. This sequence 

defines a user-defined key. Regarding the above-quoted features of claim 78, the Examiner 

rehes on column 11, line 46 to column 12, line 7 of French, which state: 

According to the present invention, the Index Manager is "taught more" about the 
problem or query at hand. In a conventional system (e.g., Oracle), the Query 
Optimizer generally asks the indexes only simple questions, such as "what is the 
record for Account No. 35?" In the system of the present invention, in contrast, 
additional complexity has been pushed ft-om the Optimizer down to a level which 
is closer to the data. In addition to requests for returning a particular record (e.g.. 
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return the record for Account No. 35) in the system, operations such as SUM, 
AVG, MIN, MAX, COUNT DISTINCT, and the like are performed at the level of 
the data objects (e.g., data pages). Because the indexes understand the distribution 
of the data, the cardinality of the data, the range of values of the data, and the like, 
the indexes are much closer to the physical problem. They understand the physical 
nature of that column's attributes. As a result, they are better suited for these types 
of operations. 

In the case of the low cardinality value-based indexing technique, doing a 
GROUP BY is computationally cheap, because the index is ordered by group. 
Similarly, COUNT DISTINCT is computationally cheap; COUNT DISTINCT is 
another v^ay of grouping things. SUM is also reasonably cheap. Consider a query 
on the number of dependents, a low cardinality field (e.g., values ranging fi-om 1 
to 10). Here, the system need only access the corresponding bit maps (i.e., 10 bit 
maps) for quickly determining how many bits are on. The Index Manager is 
modified to include an interface which allows it to receive some of the query 
information retuming a page and offset for a given key value. 
(French, colunrn 11, line 46, to column 12, line 7) 

French discloses a system in which an Index Manager is "taught more" about a problem or query 
at hand. French further discloses that indexes may be ordered in different ways such as GROUP 
BY, COUNT DISTINCT, and SUM. The Index Manager may include an interface which allows 
it to receive some of the query information retuming a page and offset for a given key value. 
French does not appear to relate to defining a sequence of elements in a key. Moreover, 
Applicant submits that French does not teach or suggest receiving fi-om a user, for each of two or 
more selected data elements displayed, an input including a sequence parameter that specifies the 
place of the data element in a sequence specifying the place of the data element in a sequence of 
the two or more data elements, the selected data elements in the user-specified sequence defining 
a user-defined key, the user-defined key being configured during a configuration of a financial 
service organization (FSO) computer system. 

For at least the reasons stated above, the combination of the features of claim 78 are not 
taught or suggested by the cited art. Applicant requests removal of the rejection of claim 78 and 
the claims dependent thereon. 
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E. Additional Comments 

Based on the above. Applicant submits that all claims are now in condition for allowance. 
Favorable reconsideration is respectfully requested. 

If any extension of time is required, Applicant hereby requests the appropriate extension 
of time. Applicant believes no fees are due with the submission of this response. If any fees are 
' required, please charge those fees to Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C. Deposit 
Account Number 50-1505/5053-31401/EBM. 



Respectfully submitted, 




Chris D. Thompson 
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